The opinion in support of the decision being entered today 
was not written for publication and 
is not binding precedent of the Board. 



UNITED STATES PATENT AND TRADEMARK OFFICE 

BEFORE THE BOARD OF PATENT APPEALS 
AND INTERFERENCES 

Ex parte OLIVIER FONCARNIER 

Appeal No. 2006-0666 
Application No. 09/407,738 

ON BRIEF 



Before: THOMAS, MACDONALD and NAPPI, Administrative Patent Judges. 
NAPPI, Administrative Patent Judge. 

DECISION ON APPEAL 

This is a decision on appeal under 35 U.S.C. § 134 of the final rejection of 
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Invention 



The invention relates to a system for broadcasting information and alarm 
messages to selected users in a data transmission network. See page 2 of 
appellant's specification. 

Claim 1 is representative of the invention and is reproduced below: 

1 . System for broadcasting alarm messages from a server to a list of users 
among a plurality of multi-platform users sharing the server in a data 
transmission network operating under Internet Protocol (IP) and using Java 
language, said system being characterized in that it comprises: 

a profile table containing profiles of each one of said plurality of users; 

and 

processing and transmitting means enabling an administrator associated 
with said server to transmit alarm messages to the list of users wherein said 
users have been selected from said profile table, said alarm messages being 
displayed on a screen of a workstation associated with each selected user if said 
workstation is running. 
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Rejections at Issue 

Claims 1,8, 15, 22 through 24 stand rejected under 35 U.S.C. § 102(b) as 
being anticipated by Ruckdashel. Claims 1, 8, 15, 22 through 24 stand rejected 
under 35 U.S.C. § 102(b) as being anticipated by Raffel. Claims 1, 8 and 15 
stand rejected under 35 U.S.C. § 103(a) as being unpatentable over Stupek. 
Claims 2 through 4, 7, 9, 10, 11, 14, 15, 17, 18 and 21 stand rejected under 35 
U.S.C. § 103(a) as being unpatentable over Stupek in view of Drala. Claims 6, 
13 and 20 stand rejected under 35 U.S.C. § 103(a) as being unpatentable over 
Stupek in view of Drala and Cote. The examiner has withdrawn the rejection of 
claims 22 through 24 under 35 U.S.C. § 112 and the rejection of claims 5, 12 
and 19 under 35 U.S.C. § 103. 

Opinion 

We have carefully considered the subject matter on appeal, the rejections 
advanced by the examiner, and the evidence of anticipation and obviousness 
relied upon by the examiner as support for the rejections. We have, likewise, 
reviewed and taken into consideration, in reaching our decision, appellant's 
arguments set forth in the briefs along with the examiner's rationale in support of 
the rejections and arguments in rebuttal set forth in the examiner's answer. With 
full consideration being given to the subject matter on appeal, the examiner's 
rejections and the arguments of appellant and the examiner, and for the reasons 
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stated infra we sustain the examiner's rejections of claims 1 , 8, 15 and 22 
through 24 under 35 U.S.C. § 102 as being anticipated by Raffel. However, we 
will not sustain the examiner's rejections of claims 1, 8, 15 and 22 through 24 
under 35 U.S.C. § 102 as being anticipated by Ruckdashel or the examiner's 
rejections of claims 1 through 24 under 35 U.S.C. § 103. 

Initially, we note that the examiner's final rejection did not include a 
rejection of claims 1 , 8 and 15 under 35 U.S.C. § 102 as being anticipated by 
either Raffel or Ruckdashel. The first time claims 1 , 8 and 1 5 were identified as 
being rejected under 35 U.S.C. § 102 as being anticipated by either Raffel or 
Ruckdashel was in the Answer. However, appellant's brief and reply brief both 
presented arguments directed the limitations of claims 1, 8 and 15 in relation to 
the disclosures of Raffel and Ruckdashel. Thus, the record shows that appellant 
anticipated the rejection of claims 1, 8 and 15 under 35 U.S.C. § 102 as being 
anticipated by either Raffel or Ruckdashel. Further, as appellant has not 
contested whether the examiner's new ground of rejecting claims 1 , 8 and 15 is 
properly before us, we consider appellant to have waived such an argument and 
we consider the new grounds of rejection to be properly before us for review. 

Rejections based upon Stupek 

Appellant argues, on page 9 of the brief: 

Stupek is concerned with performing network management functions, 
much like the Simple Network Management protocol (SNMP) and the 
Desktop Management Interface (DMI), across the Internet using a web 
browser. Although Stupek may allow for the client to define certain 
preferences and identify certain data to be monitored, there is nothing in 
Stupek that teaches or even suggests an administrator associated with a 
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server sending alarm messages to a list of users, selected from a plurality 
of users within a profile table as recited in claims 1, 8 and 15 of the 
present invention. 

Appellant asserts that the sections of Stupek that the examiner relies upon to 
support this teaching describe the interaction between a user and the 
management server, but that Stupek does not teach transmitting an alarm 
message to users selected from a list of users in a profile table. 

On page 3 of the answer, the examiner identifies that the term "profile 
table" is interpreted as "a table for storing users' profile information, which is 
equivalent to Stupek's database, which also storing user profile or preference 
information (Stupek at col. 5, lines 50-53)." Further, the examiner identifies, on 
pages 3 and 4 of the answer, that the term "the list of users" is interpreted as "a 
conventional database filtering manner to form a list or group of uses [sic, users] 
for receiving alarm, for instance, selecting by name, demographic, activity, 
hobby, preference, information subscribing type, communication devices type, or 
other information, which may be included in users profile." In response to 
appellant's arguments the examiner asserts, on page 13 of the answer, that 
Stupek in col. 1, line 63 through col. 2, Iine15 and col. 5, line 47 through col. 6, 
Iine15, discloses a network management system capable of transmitting alarm, 
event notification to a group of managed devices, which have their profile stored 
in database, e.g. profile table. Further, the examiner asserts: "It would have 
been obvious to one of ordinary skill in the art to expand the used [sic, user] of 
Stupek by merely modifying roll [sic, the role] of [the] user in Stupek to act as a 
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well-know[n role] of administrator for sending [an] alarm to all selected users 
rather than Managed device." 

While we concur with the examiner's claim interpretation, we disagree with 
the examiner's findings regarding the teachings of Stupek. Claim 1 recites " a 
profile table containing profiles of each one of said plurality of users", 
"processing and transmitting means enabling an administrator associated with 
said server to transmit alarm messages to the list of users." Independent claims 
8 and 15 contain similar limitations. Thus, the claims recite at least two types of 
entities: an administrator and a user. The claims do not define what makes an 
entity an administrator, other than an entity who is enabled to transmit messages 
to users. Further, the claims do not define what makes an entity a user, other 
than having a profile in the profile table and being associated with a workstation. 

Stupek teaches a management system where a management network 
allows for the management of both hardware and software. The system makes 
use of a management server, managed elements and a client system. The 
managed elements can be computers or other network equipment. See column 
4, lines 14 through 43. A user can use the management server to select a 
managed element and view information about the device. See column 6, lines 7 
through 14. The user, through the management server, can set a threshold 
which is used to monitor an event in the managed device, the management 
server then provides a notification or message to the user when the conditions 
are met, an event occurs. See column 7, lines 10 through 20. 
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While we consider the event messages of Stupek to meet the claimed 
alarm massages, we do not find that these messages are generated by one 
entity, an administrator, and transmitted to another entity, a user, selected from a 
profile table containing profiles of users. We do not find, as the examiner 
asserts, that Stupek, in column 5, lines 46-67, teaches a profile table from which 
users, to receive the event messages, are selected. Rather, we find that that the 
cited section of Stupek teaches that the management server maintains a 
database of data to be monitored and that this database includes user 
preferences. Thus, we find no teaching or suggestion in Stupek that the system 
makes use of a profile table to identify a list of users to receive an event 
notification and we will not sustain the examiner's rejection of claims 1, 8 and 15 
under 35 U.S.C. § 103. 

The examiner has rejected claims 2 through 4, 7, 9, 10, 11, 14, 15, 17, 18 
and 21 under 35 U.S.C. § 103(a) as being unpatentable over Stupek in view of 
Drala. The examiner has not asserted, nor do we find that Darla teaches or 
suggests modifying Stupek such that the system makes use of a profile table to 
identify a list of users to receive an event notification. Accordingly, we will not 
sustain the examiner's rejection of claims 2 through 4, 7, 9, 10, 11, 14, 15, 17, 18 
and 21 under 35 U.S.C. § 103(a). 

The examiner has rejected claims 6, 13 and 20 under 35 U.S.C. § 103(a) 
as being unpatentable over Stupek in view of Drala and Cote. The examiner has 
not asserted, nor do we find that either Darla or Cote teaches or suggests 
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modifying Stupek such that the system makes use of a profile table to identify a 
list of users to receive an event notification. Accordingly, we will not sustain the 
examiner's rejection of claims 6, 13 and 20 under 35 U.S.C. § 103(a). 

Rejection based upon Ruckdashel 

Appellant argues, on pages 23 and 24 of the brief, that Ruckdashel does 
not teach an administrator sending alarm messages to a list of users selected 
from a plurality of users as claimed in the independent claims. 

The examiner responds that the statement of the rejection and citations of 
Ruckdashel in the rejection are self-explanatory. 

We disagree with the examiner. Ruckdashel teaches a system where by 
a user's individual scheduling information is analyzed and when the event arrives 
the user is notified in a manner of their choosing i.e. paging, e-mail or wireless 
phone. See abstract. Ruckdashel teaches two entities the individual users and 
an administrator. Ruckdashel teaches that the administrator performs tasks 
such as managing the software that provides the notification. However, 
Ruckdashel does not teach that the administrator transmits the messages to the 
list of users, rather the users sign up and the system transmits the messages. 
We note that Ruckdashel identifies that systems such as Microsoft Schedule+ 
are used to provide the user's schedule information. The role of the claimed 
administrator may be inherent to such scheduling programs as it is our 
experience with such programs that a person setting up a meeting with such 
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programs typically selects invitees to the meeting from a table of users with 
profiles. However, the examiner has not made this argument nor is there any 
evidence of record to support such a finding. Accordingly, we do not find that 
Ruckdashel anticipated claims 1 , 8, 15 and 22 through 24. 

Rejections based upon Raffel 

Appellant argues, on page 22 of the brief, that Raffel does not teach an 

administrator associated with a server sending alarm messages to a list of users 

selected from a plurality of users within a profile table. Appellant reasons that 

Raffel is directed to a system for providing transactional information of deals, 

contracts, accounts and leads over the internet and where the administrator can 

configure the system to notify users every time there is new or changed 

information for accounts or deals for which the user has access. Appellant 

states, on pages 22 and 23 of the brief: 

While Raffel may teach sending a notification to a user, there is nothing in 
Raffel that teaches that an administrator associated with a server sends 
an alarm message to a list of users, selected from a plurality of users, 
within a profile table. To the contrary, the administrator in Raffel 
configures the system to automatically send out notifications as stated in 
paragraph 0082 of Raffel. 

Further, appellant states "[cjlaims 1, 8 and 15 of the present invention recite that 
the administrator sends the alarm to a list of users, selected from the plurality of 
users within the profile table. This is a manual process performed by an 
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administrator and not an automatic process such as taught by Raffel." Appellant 
presents similar arguments on page 8 of the reply brief. 

While we agree with the appellant's description of Raffel, we are not 
persuaded by appellant's argument as it is not commensurate with the scope of 
the claim. We find no limitation claim 1 which limits the processing and 
transmitting of the alarm message by the administrator to a manual process. 
Appellant's specification identifies, on page 4, that messages can be generated 
automatically. Further, claim 4, which further limits claim 1 , identifies that the 
alarm message is automatically sent by the processing and transmitting means. 
Thus, we consider the scope of claim 1 to be broad enough to include both a 
manual transmission and an automatic transmission of the alarm message. As 
appellant admits, on page 23 of the brief "the administrator in Raffel configures 
the system to automatically send out notifications." Accordingly, we sustain the 
examiner's rejection of claim 1 under 35 U.S.C. § 102. 

Appellant has presented no arguments directed to why claims 8, 15 and 
22 through 24 are separately patentable from claim 1 . Accordingly we group 
claims 8, 15 and 22 through 25 with claim 1 and we sustain the examiner's 
rejection of these claims under 35 U.S.C. § 102 for the reasons provided with 
respect to claim 1 . 
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Conclusion 

In summary, we sustain the examiner's rejection of claims 1, 8, 15 and 22 
through 24 under 35 U.S.C. § 102 as being anticipated by Raffel. However, we 
will not sustain the examiner's rejection of claims 1,8, 15 and 22 through 24 
under 35 U.S.C. § 102 as being anticipated by Ruckdashel or the examiner's 
rejections of claims 1 through 24 under 35 U.S.C. § 103. The decision of the 
examiner is affirmed-in-part. 

No time period for taking any subsequent action in connection with this 
appeal may be extended under 37 CFR §1.1 36(a)(1 )(iv). 

AFFIRMED-IN-PART 
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